Amiga Developer CD 2.1/Amiga Developer CD v2.1.iso/Reference/Amiga_Mail_Vol2/Archives/Plain/ja90/TAS.txt

Text File | 1991-01-22 | 19.1 KB | 377 lines

Amiga TAS Cycles

A Study of the Viability of the TAS Instruction on the Zorro II
Bus

by Dave Haynie

There has been a considerable amount of confusion about the use of the
TAS, or Test And Set, instruction on Amiga systems for quite some
time.  Historically, the 68000 implementation of the bus lock required
by TAS has been a headache for many 68000 system designers, and Amiga
engineers haven't been excluded from this.  While the problem of TAS
alone is an important issue, the evolution of official TAS support on
Amiga systems further complicates the matter.  This article won't give
a clear answer to the "can I use TAS" question, since that answer
changes based on the context of TAS's use.  What I'm trying to do here
is explain why TAS is a problem, what various Amiga systems do with
TAS, and when TAS might be safely used by a Zorro II expansion
board.

The Need For TAS?

The TAS instruction is designed to support hardware locked semaphores
between multiple processors in a system.  The idea is that making a
read cycle, ALU operation, and write cycle an atomic operation will
allow the 68000 to check on the value of a semaphore in memory and set
this semaphore if currently unset, all without the possibility of
another processor gaining access to the memory in between the read and
write phases.  Presumably, as long as shared structures in a
multiprocessing system are all guarded by semaphores, and all
semaphores are obtained under bus lock protection, then the
possibility of uncontrolled simultaneous access of these shared
resources is eliminated.

In the general case, this is called bus locking, and it's a
perfectly valid concept.  The problem stems from the way the 68000
designers chose to lock the bus.  This TAS-generated bus lock becomes
a special case 68000 cycle that's often not correctly supported by
hardware.  For this reason, TAS should never be used on Zorro II
devices that aren't specifically designed to support it.  As long as
you're not dealing with multiprocessor systems, TAS isn't necessary.
The remainder of the document will be concerned with multiprocessing
systems; the cases in which TAS is very useful, if not actually
necessary.

It should be noted that the TAS instruction is neither necessary nor
supported on the Amiga's Chip memory bus.  Although the Amiga's
blitter and Copper do serve to provide a form of multiprocessing on
the Chip bus, this is a specialized multiprocessing where the blitter
and Copper basically act as slaves to the main 680x0 processor.  The
TAS instruction is used to support structure locking between peer CPUs
which both share the same Amiga OS structures.  Any alternate
processor that acts as a slave, such as the Amiga chips or perhaps a
DMA device, will not share system structures and therefore, do not
need the hardware bus locking provided by TAS.  Also, the design of
the Chip bus makes it impossible to support any use of the 68000 TAS
instruction to Chip memory anyway.  The custom chips get bus access
for two out of every four system clock cycles, holding the 68000 off
when they're on the bus.  The double TAS cycle conflicts with this
mechanism, yielding unpredictable results.



A 68000 Bus Locking Primer

As mentioned, the problem with the use of TAS is primarily
based on the way the 68000 implements its bus locking.  Unlike 68020
and 68030 processors, which drive a special Read-Modify Cycle signal
(RMC*) to indicate bus locking, the 68000 runs a modification of the
normal 68000 bus cycle.



******************* FIGURE 1 ******************



The normal 68000 bus cycle starts with the assertion of addresses and
the read strobe (R/W), followed shortly by the assertion of address
strobe (AS*) and the data strobes (UDS* and LDS*).  AS* is asserted
during state S2, while the data strobes are asserted during state S2
for read cycles, state S4 for write cycles.  The 68000 drives data for
write cycles just before the data strobes, and samples data on read
cycles on the falling edge of its clock at state S6.  In either case,
it samples the data transfer acknowledge strobe (DTACK*) on the
falling edge of state S4, and inserts wait states until DTACK* is
asserted.  Once DTACK* is sampled, the cycle concludes with AS*, UDS*,
LDS*, and most other signals being negated during S7 or shortly
thereafter.  Figure 1 illustrates a standard 68000 read and write
cycle.

The above read cycle followed by write cycle is quite sufficient for
handling semaphores in a single processor system, if supported within
a single instruction.  The 68000 family CPUs don't permit interrupts
to be serviced except at instruction boundaries.  So the 68000 bit
test instructions are adequate to support software semaphores in an
interrupt driven multitasking single processor system.  Bus
arbitration, on the other hand, is managed at cycle boundaries for the
most part.  Ordinary I/O DMA devices such as hard disks don't
interfere with this locking either, since such DMA devices don't
access system structures.  All 680x0 locked cycles, including TAS,
complete atomically even in the presence of a pending DMA request, so
true bus locking isn't strictly necessary to handle semaphores between
DMA processors using normal 680x0 bus arbitration to share memory.  A
bus locking mechanism is, however, the proper way to handle resource
locking of structures in a cycle-shared mailbox memory, such as the
shared memory that's implemented on Amiga Bridgecards.



******************* FIGURE 2 ******************



The 68000 TAS cycle works much like a normal read followed by a normal
write, except that AS* is not negated between the read and write
portions of the compound cycle.  Bus devices that expect AS* to
qualify cycle boundaries, or devices that anticipate a minimum delay
between the assertion of DTACK* and the negation of AS*, will fail
with TAS cycles.  Both AS* and the data strobes must be used to
identify the subcycle boundaries within the full TAS cycle.  The bus
address doesn't change throughout the cycle, while the R/W line and
data bus obey the timing of the individual subcycles.  DTACK* and
other slave device signals will similarly respect the timing of the
individual subcycles, as based on UDS* or LDS*.  Additionally, the TAS
cycle contains extra clock cycles for the ALU operation, so that
instead of the minimal eight clocks for a read cycle immediately
followed by a write cycle, the minimum TAS cycle takes ten clocks.
Figure 2 illustrates a 68000 TAS cycle.



Zorro II Bus Issues

The Zorro II expansion bus, being originally based on the 68000 CPU
bus, by extension can run TAS cycles.  However, their use on the Zorro
II bus is far from straightforward.  Although the original Zorro II
specifications and the updated specifications published in the
A500/A2000 Technical Reference Manual both require the M68000
Users Manual as a companion specification, the use of TAS was never
explicitly discussed for use on the bus.  Additionally, the use of TAS
in Amiga Chip memory was explicitly forbidden, and at the time of the
Zorro II specification writing, generally considered unsupported
anywhere on Amiga computers.

Because of this ambiguity, many Zorro II devices don't support TAS
cycles at all.  Therefore, the use of TAS is explicitly forbidden on
any Zorro II device that isn't specifically known to support TAS.
Even simple memory boards probably act unpredictably when driven with
a TAS cycle.

Circuits that do support TAS must be very carefully designed
to support it properly.  Due to clock skewing between the 68000 and
the backplane, or alternate bus masters and the backplane, no Zorro II
slave PIC that controls DTACK* via XRDY must assume it knows the delay
between its negation of XRDY and the end of the cycle.  For any
XRDY-controlled Zorro II cycle, the cycle's end is defined by the
negation of AS* or UDS*/LDS*, which ever comes first.  This is a
general rule (nothing specific to the TAS cycle), but one would expect
the situations in which TAS is necessary, such as locking shared
memory resources, to be more sensitive to any cycle delays.  All
shared memory circuits must have some kind of memory arbiter, and such
arbiters might be easier to design considering only outgoing signals
such as XRDY.  However, designs that don't use AS* to end normal
cycles and UDS*/LDS* to end the read half of the TAS cycle are very
likely to cause trouble.



******************* FIGURE 3 ******************



Figure 3 illustrates how a reasonably designed XRDY based control
circuit can possibly result in an unexpected wait state.  This example
is assuming A2000 system timing.  Essentially, what this hypothetical
device wants to do is terminate the current cycle by negating the XRDY
line that it pulled properly at the start of the cycle.  The XRDY
signal is being driven on the rising edge of the 7MHz clock, the
result of a synchronous state machine that runs with 7MHz timing.

The A2000's Zorro II bus uses a buffered version of the 68000's
7MHz clock.  This can introduce clock delays of roughly 10ns between
the actual 68000 clock and the bus clock.  The hypothetical circuit
uses the rising edge of the clock to enable XRDY.  I'm assuming a
total worst-case delay of 35ns here, which must take into account the
PIC logic in the XRDY path: clock buffer, flip-flop and state machine
logic, and an open collector output buffer to drive XRDY onto the bus.
While XRDY circuits may be faster in some designs, this example is not
unreasonable.  Once XRDY is asserted, there's the Gary chip delay to
consider, which can be slower than 25ns in worst case.  Thus, in this
example, DTACK* isn't asserted until over 70ns after the real 7MHz
clock transition, even ignoring other small delays that can be
incurred by bus loading or assymetry of the 7MHz clock.  In order to
assure that DTACK* is sampled by the 68000 without an additional wait
state, it must be asserted by the 68000 at least 10ns prior to the
falling edge of the 7MHz clock.

Clearly, we're missing that in this example by at least 10ns, so the
wait state is added.  Any logic on this hypothetical card that assumed
the cycle would be over two clocks after XRDY was clocked will fail.
Likewise, logic on that card that assumes the extra wait state will
always be added would be just as fatal.  This example assumes worst
case, but in a best case situation, the wait state would never happen.

Also, the characteristics of the Zorro II bus interface come into
play.  An A2000 may take 25ns to recognize XRDY, but another backplane
may treat it faster or slower.  The XRDY signal has always been
treated as an asynchronous signal, and there is no guaranteed range of
synchronous operation defined for this signal.  The AS* or UDS*/LDS*
defined end of cycle must always be explicitly considered by a proper
Zorro II XRDY controlled slave device (this is also a requirement
defined by the 68000 specifications, though they don't explain the
likely problems of not being strobe driven) [see footnote]***.

***[footnote] I don't claim these problems should be immediately
obvious to everyone.  Once mentioned, it should be pretty easy to
recognize that pre-supposing the end of a bus cycle is dangerous.  I
ran into this exact type of problem in the B revision of the A3000's
Buster chip, so it can happen to anyone.  The current Buster, like any
good design, is basing its end-of-cycle actions on the negation of the
appropriate strobes, never the assumption on when DTACK* will take
effect.

Any designs that must behave synchronously must assert OVR* to release
the backplane's control of DTACK*, and then drive DTACK*
synchronously.  The Zorro II requirements for synchronous operation
with DTACK* controlled termination require that DTACK* be set up to
the falling edge of S4 by 30ns, which is a sufficient amount of time
to meet both the actual 68000 setup time and offset the effect of any
clock skews on the backplane.  Alternate bus masters such as DMA
driven hard disk controllers must of course take into account
synchronous operation with DTACK* as one of the list of bus
constraints they must meet.



TAS and the A2500

At the time the A2620 and A2630 were designed, the use of TAS on the
expansion bus was still considered a dubious practice.  While TAS can,
within the limits set forth in this document, be used successfully on
some Amiga system, it is not completely supported in either A2500
configuration.  As mentioned, the TAS cycle performs two major
functions.  The first, which is supported by the A2500, is to provide
an atomic cycle that will arbitrate a semaphore between DMA devices on
the bus.  With A2500s, TAS is guaranteed to be atomic with respect to
bus arbitration.  However, it does not generate 68000 compatible TAS
cycles on the expansion bus.  The TAS instruction executed on either
A2500 system will result in a standard 68000 read cycle followed by a
standard 68000 write cycle.  Thus, there is no bus locking, so TAS
won't be sufficient to arbitrate semaphores in shared mailbox type
memory.  The best solution for such mailbox arbitration is to use
software based spin lock semaphores or other methods which permit safe
multiprocessing semaphores without the hardware bus locking.  If
that's unacceptable for all Amigas, the TAS solution can be invoked on
Amiga systems that support it, while the software-only solution can be
invoked on A2500s or other 2500-class machines.  Software can
determine the existence of a real A2500 by querying for an A2500 via
the expansion library.  A2500s show up as Commodore products
(manufacturer number $0202) numbers $50 (for A2500/20) or $51 (for
A2500/30).

While you can explicitly check for operation on a true A2500, you
cannot as easily determine in all cases if the machine is a similarly
enhanced A2000 running with a third party accelerator board.  Without
autoconfiguration units such as on real A2500s, software can only tell
the CPU type.  Some third party coprocessor boards are available
without memory or other permanent autoconfiguration units that
software could use to identify the accelerator manufacturer.  Even
some of those boards with memory don't autoconfigure it like they
should.  Commodore does not have a list of which (if there are any)
third party accelerator cards will fully support TAS cycles anyway.
It is therefore important to assume that any 68020 or 68030 Amiga,
except for the A3000, is not likely to support TAS and should instead
handle bus locking in software.



TAS and the A3000

The A3000 does support 68000 compatible TAS cycles on its
implementation of the Zorro II bus, but there are some caveats that
must be considered.  Any differences from the A3000's implementation
of the 68000-compatible TAS cycle stem from the fact that TAS is
handled differently by the 68030.  The primary difference in 68030 TAS
handling is that the 68030 runs two standard 68030 cycles in response
to TAS, and locks the bus by way of the RMC* signal.  Also, while the
68000 specified the length of the ALU cycle between the read and write
phases of the TAS instruction, the 68030 specifications do not
quantify this part of the cycle.  When supporting the 68000 TAS cycle,
the A3000's CPU is also running asynchronously to the Zorro II bus, so
clock synchronization delays also creep in.

The result of all of this is that the length of the entire Zorro II
TAS cycle on the Amiga 3000 bus can vary by one, and possibly two,
7MHz clock cycles.  The A3000 TAS cycle is shown in Figure 4.  The
A3000 starts all bus cycles as Zorro III cycles, with the assertion of
the Full Cycle Strobe (FCS*) shortly following the 68030's assertion
of AS*.  When a Zorro II cycle is indicated, FCS* is sampled on the
falling edge of CDAC, and then on the rising edge of the 7MHz clock.
The diagram shows where FCS* and AS* might have been to give rise to
the Zorro II cycle starting here.  The double-clocked FCS* will
quickly create the A3000's 68000 compatible address strobe, CCS*, and
in the case of a read cycle, the UDS*/LDS* equivalents called DS3* and
DS2*, respectively.

The remainder of the read phase runs just as a 68000 cycle until
DTACK* is sampled at the falling edge of S4.  DTACK* would normally
cause CCS* and the data strobes to be negated at S6, but since this is
a TAS cycle, only the data strobes are negated.  Also at this point,
the expansion bus data is latched for the 68030 and the 68030's
DSACK1* signal is asserted on the A3000's local bus.  This is the
first cause of the cycle length ambiguity.  The 68030 is of course
running asynchronous to the Zorro II cycle in progress, and so the
time between the assertion of DSACK1* and the 68030's negation of AS*
can be as quick as 40ns, for an A3000/25 that just manages to hit
DSACK1* at the sample point.  It might also be as long as 120ns for an
A3000/16 that just misses the sample point.  If the worst-case timing
of the 68030 is considered, this last delay could actually be as long
as 150ns.  Once AS* is negated, DSACK1* will be negated and the 68030
cycle ends, though the Zorro II within Zorro III cycle-in-progress
remains active.



******************* FIGURE 4 ******************



The next half of the TAS cycle starts with the 68030's assertion of
AS* again.  There is more cycle length ambiguity introduced here,
since the 68030 specification does not document the number of clocks a
TAS ALU cycle will take.  Since any 68030 clock cycle is only a
fraction of a Zorro II cycle, this isn't expected to be a drastic
ambiguity, but it's something to consider.  Since the FCS* strobe is
already asserted, the A3000 bus controller effectively samples AS*,
first with the falling CDAC clock and then with the rising 7MHz clock,
to start the write section of the TAS cycle.  Based on the intercycle
ambiguities as seen from the 68030's perspective, this second bus
cycle will sometimes start early, other times late.  Figure 4 shows
the likely best and worst case secondary cycles, which ultimately
depend on whether or not AS* is asserted quickly enough to be clocked
by the falling CDAC in S11, or whether it must wait until S13.

However that gets settled, the bus controller drives DS3*/DS2*,
samples DTACK*, and ultimately negates both data strobes and CCS*.
Following this end of the Zorro II cycle, the DSACK1* strobe is
asserted onto the local bus, the 68030 sees this within 40ns or 60ns
of it being asserted, and AS* followed by DSACK* are negated, ending
the local bus cycle.  FCS* is quickly negated based on AS*, and the
cycle ends.



The Final Word

So that's a fairly complete description of the behavior of TAS on all
currently known implementations of the Zorro II bus.  While things
like XRDY to cycle's end and the total length of the TAS cycle aren't
always the same between the different backplanes, this doesn't matter
for correctly designed expansion cards.

Use XRDY for asynchronous operation, OVR*, DTACK*, and C7M for
synchronous or asynchronous operation.  Any cards that find this does
matter should avoid using TAS, since they will get into trouble sooner
or later.  The main concern to devices that want to support TAS will
be the incomplete operation of TAS in A2500 and 2500 look-a-like
systems.  These devices must provide some software lock mechanism when
on an A2500, which can be replaced with hardware locking on 68000
based Amigas and A3000s, if necessary.

An A3000 specific design can be a Zorro III card and use the /LOCK
signal and the TAS, CAS, or CAS2 instructions for bus locking,
bypassing all the 68000-inspired nonsense completely.